-
Notifications
You must be signed in to change notification settings - Fork 897
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow Vmdb::Plugins to work through code reloads in development. #15057
Conversation
This looks good to me. @bdunne did you have reservations with this? |
lib/vmdb/plugins.rb
Outdated
@vmdb_plugins.empty? ? register_from_railties : @vmdb_plugins | ||
end | ||
|
||
def register_from_railties |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor, but I think I'd prefer the method to be called register_vmdb_plugins
.
- The name matches the initializer name
- The name mirrors the singular method
register_vmdb_plugin
, so you know it's registering all of them - that the plugins are found via railties now is an implementation detail and is subject to possibly change.
@hayesr What clears out the |
@Fryguy The data is only loaded in an initializer now, so I think when the constant/singleton is reloaded that step is skipped (ie |
3cc8609
to
81b44aa
Compare
Checked commits hayesr/manageiq@587eb0f~...81b44aa with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 LGTM
Currently plugins are registered with
Vmdb::Plugins
at boot. This is fine for production but in development a file change will cause a code reload which clears out plugin information.This change still loads plugin info in an initializer, but reloads it if it has been cleared.